home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 13796 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.1 KB
  1. Path: locutus.rchland.ibm.com!usenet
  2. From: Philip Staite <pstaite+@rchland.ibm.com>
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: 'new' & 'delete' memory management
  5. Date: Wed, 27 Mar 1996 07:57:17 -0600
  6. Organization: IBM Rochester, MN
  7. Message-ID: <3159493D.167E@rchland.ibm.com>
  8. References: <4j81ce$ivk@umt.umt.edu>
  9. NNTP-Posting-Host: powertool.rchland.ibm.com
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 2.01 (X11; I; AIX 1)
  14.  
  15. Ho Hsin wrote:
  16.  
  17. > 1) How do new and delete manage memory at a low level (ie. the internal
  18. > working of new and delete.)
  19.  
  20. Many don't ;-)  Many C++ RTL implementations just call malloc and free
  21. from the C RTL under the covers.  Your question is a little broad, what
  22. exactly do you want to know?  Allocation strategy, deallocation and
  23. fragmentation recovery?  Block chains vs directory list?  Minimum
  24. allocation size and space overhead?  Paging strategy?...
  25.  
  26. Finally, implementations can and do vary quite a bit.  There are lots of
  27. good ways of "managing" memory within new/delete malloc/free with
  28. various tradeoffs.
  29.  
  30.  
  31. > 2) Does it coalesce small blocks of memory after delete to prevent
  32. > fragmentations? How does it do it (ie. algorithm) ?
  33.  
  34. Yes, no, maybe, sometimes...  Depends on the system and library.  Some
  35. policies in use are:
  36.  
  37. 1) Always concatenate on the free.
  38.  
  39. 2) Concatenate on the allocate (ie, is this free block too small?  Is
  40. there another adjacent free block?...)
  41.  
  42. 3) Don't concatenate (ever, but use a best-fit allocation scheme).
  43.  
  44. 4) Concatentate only when there are no more free blocks available of
  45. sufficent size.
  46.  
  47. 5) etc. -- probably a couple I've forgotten about.
  48.  
  49. > 3) Page or virtual memory is handled by the OS of the system. I would
  50. > like to know how is memory manage within a page?
  51.  
  52. On some systems it isn't.  That is, the smallest allocation unit from
  53. the OS is a page (typically 4096 bytes).  The C/C++ RTL will get memory
  54. from the OS in multi-page "chunks" and then suballocate it as needed.
  55. On other systems the RTL may be "lazy" and let the OS memory manager do
  56. all the work.
  57.  
  58. -- 
  59.  
  60. Phil Staite, (507) 253-2529, team OS/2
  61. internet: pstaite@vnet.ibm.com  internal: pstaite@rchland
  62.